Maybe it's time to open issues on the browsers with this change?

@cookiecrook thank you for the review.

per your two comments:

...that this doesn't seem to account for native-reserved roles...

it was definitely the intent to account for that, so happy to incorporate changes to make sure that's included / I'll have a think on other wording to make sure that's clear.

re:

so I am not certain it's a good change to force promotion of something like <div contenteditable> when the author may have added the relevant role and label to another nearby container.

that's an interesting idea. Though it makes me think back to past projects I worked on - one being a website builder where there were blocks of editable areas within predefined templates. So a main could have 2 or 3 contenteditable divs within it. Something to think about...

per your two comments:

FYI Our comments crossed when I added a third to the list: contenteditable="false" or contenteditable="plaintext-only" override cascades on sub-sections may not need explicit roles... example above.

@cookiecrook we had talked about false not triggering a need for a minimum role. In the comments for contenteditable it indicates the minimum role only changes if the value is true. I have a comment in the source code to mention what happens with plaintext-only when that is added to the standard.

We had a deep dive this morning, it seems the main conclusions were:

• to remove the minimum role of group from contenteditable, as there is already a history of browsers/ATs attemping to make contenteditable work and we can't be sure if making those elements "group" would make things better or worse.
• there was agreement that the minimum role of contenteditable=plaintextonly could be "textbox"
• there was quite a bit of discussion about whether or not "minimum role" was the right language (instead of "implicit role for this attribute", opponents say the "implicit role" has a specific meaning related to the tagname so sound cause confusion). @mcking65, who thought it was unclear, committed to reviewing this PR in order to understand.
• It was decided not to use the language "fallback" because that implies that authors shouldn't rely on the minimum role, when in fact, the aim is to allow them to rely on the minimum role. If adding an attribute makes the semantic meaning of the element clear, then you shouldn't need to also add a role. Therefore validators will have to be updated to not report errors when these attributes are used on elements with no implicit or explicit roles.

It was decided not to use the language "fallback"

Also that term had been used to describe the fallback roles such as role="switch checkbox" where checkbox was the ARIA 1.0 fallback role if the engine did not yet support the ARIA 1.1 switch role.

I somehow missed this altogether, so no, i haven't looked at it. I'll endeavour to do so soonish.

I'm trying to grasp exactly what this gives us that we didn't have before:

1. I thought the spec currently required that focusable elements were exposed in the tree, but it seems it doesn't. So, I guess this makes it clear that <div tabindex="0"> should be exposed, for example. Is that a primary intention here?
2. As far as I know, accesskey is only useful on something that is focusable. So the accesskey is probably covered by the tabindex case.
3. Is there an advantage of using "group" over "generic"? From what I've seen, group is not normally a role that is focusable. Group is no worse than generic, I guess, but generic is what some browsers already expose in cases like these, so I'm wondering why the change here rather than reflecting what already happens in some cases.
4. I do understand that this might be necessary for future proposed features, so if we're just setting up groundwork here, that's fine. I'm just trying to understand the impact on current features first.

hi @jcsteh, thanks for giving this a review, and yes, your final point is definitely the crux of this proposal - create consistency in how these and other future / semi-present (popover) global attributes are handled, so that the different browsers and AT can coalesce around how generic elements, which should generally be ignored, can be exposed to users / handled by authors.

Some more comments related to your other questions:

1. Yes, this is meant to not only explicitly identify that focusable elements need to be exposed, but help to standardize how. E.g., moving focus to a generic div when using firefox/chrome produce no announcement of any role with JAWS/NVDA, right now. But presently VoiceOver and Narrator will announce this same element as a 'group' (putting aside whether because the API is already exposing this as a group, or this is just how they presently decided to announce a generic which has been marked as important in the a11y tree).

2. regarding accesskey (but also draggable), agreed that these attributes will commonly be used on focusable elements - but since they're global attributes, they don't have to be.

3. The primary advantage again comes down to consistency / match what is already happening in some cases. Allowing AT to expose a 'group' role arguably being more meaningful than exposing a 'generic' role, or having the AT or browser come up with their own unique role description for a generic. Standardizing around 'group' could then allow consistency in how such elements were named, or not, or how if they had a title attribute, or other globally allowed aria-* attributes which are allowed on generics but often don't' get exposed to users in an overt way (if at all), they could instead be exposed in the manner in which they are with the group role.

1. Yes, this is meant to not only explicitly identify that focusable elements need to be exposed, but help to standardize how.  E.g., moving focus to a generic div when using firefox/chrome produce no announcement of any role with JAWS/NVDA, right now.

From what I can see, focusing a div produces exactly the same result as focusing a group with NVDA, except that a div reports "section" and a group reports "grouping".

2. regarding `accesskey` (but also `draggable`), agreed that these attributes will commonly be used on focusable elements - but since they're global attributes, they don't _have to be_.

accesskey is interesting in that it is global, but as far as I can tell, it isn't useful if the element to which it is applied is not focusable. Firefox and Chrome both currently expose accesskey on a non-focusable element via accessibility APIs, but pressing the access key does nothing. This raises the question of whether we should be exposing this at all in this case, since it's misleading to the user. Making that decision is probably out of scope here, but it does impact whether we bother having a minimum role in this case. I can't see a benefit given the above.

3. The primary advantage again comes down to consistency / match what is already happening in some cases.  Allowing AT to expose a 'group' role arguably being more meaningful than exposing a 'generic' role, or having the AT or browser come up with their own unique role description for a generic.  Standardizing around 'group' could then allow consistency in how such elements were named, or not, or how if they had a `title` attribute, or other globally allowed `aria-*` attributes which are allowed on generics but often don't' get exposed to users in an overt way (if at all), they could instead be exposed in the manner in which they are with the group role.

The problem here is that this assumes either that group is entirely intuitive as a fallback or that it is already being used like this, and I'm not convinced either of these is true. As I noted, unless I'm missing something, group was never really intended to get focus itself, but rather, to be a container for other focusable elements. In that sense, group is no better than generic because in either case, it's not being used for its intended semantic purpose.

To put this another, more practical way, if a screen reader user tabs to something and just hears "group", they're not going to know what it is. That's no better to the current situation where the user might tab to something and hear just "section", which is also meaningless. Arguably, it's worse because "group" has existing semantic meaning. At least with generic, screen readers could potentially say "unknown element" or something like that, which would signal to the user that the screen reader doesn't have sufficient information about what this is.

had a call with aaron and james today
agreed that accesskey can be dropped from this
no disagreement about introducing the concept
still not 100% on tabindex, but not against it - it's just a change that may create other issues to review (re: naming divs with title which are now groups because of tabindex=0)
can this be merged with the other work i'm doing for contextual role (proably?)

i need to work though if this should be merged, or can be revised into contextual role. i'll work on that soon

@scottaohara what's the update on this? Which attributes should we start with?

OK, finally got back to this and resolved all the merge conflicts. The PR is much simpler to review now in the diff mode.

This now adds the minimum role concept, and to start we're indicating this will occur for the draggable and autofocus attributes.

tabindex is presently not part of this PR (well, it's commented out for further investigation/discussion).

I plan on some editorial revising of this section with the contextual role PR (#484) - but need this to merge first before I work on that anymore.

I think this finalizes the outstanding conversations for this PR (with any potential addition of tabindex being it's own topic for the future)

cc @aleventhal @cookiecrook @jcsteh @benbeaudry

Still LGTM.

+1!

merged via w3c/aria#2220